Motivation and Context

We would like to analyze the impact of non-static object manipulation through the new physics integration introduced by PR #91 .

This PR adds benchmarking for use of kinematic(default) and dynamic(Bullet physics) objects in habitat sim to benchmark.py with rgb and rgbd sensor modes.

Added new benchmark for time inside step function.

Added benchmark script parameters for number and type of object to simulate during benchmark.

To accommodate testing, MotionType has been added to python bindings in a physics module.

Bug fix: timestep was not making from config file to PhysicsManager initialization.

How Has This Been Tested

Local and devfair benchmarking:

Setup:

• 10 cheezit boxes are loaded into a grid above the skokloster castle scene center table.
• Simplified bounding box collision meshes are used for dynamics.
• Each call to simulator.step() requests 1/60 sec simulation duration.
• Fixed timestep of 0.004166... is used to step the simulation forward. Requested simulation duration is truncated to increments of the fixed timestep (4 updates per sim step)
• Each step, all active objects are moved (kinematic) or activated and shoved (dynamic).
• FPS to realtime factor can be computed as: FPS*4*0.004
• run python examples/benchmark.py --enable_physics

Results of kinematics benchmark on devfair:

Results of dynamics benchmark on devfair:

With 10 cheezit objects (simplified):

With 10 chefcan objects (complex meshes):

Benchmark notes:

• Includes rendering of 10 additional objects when phys is enabled.
• Cheezit box is likely the simplest collision mesh we will find
• Kinematics (with additional object rendering) results in 6-9% slowdown.
• Dynamics with rgb seems similarly costly to adding depth sensor for 10 simple (cheezit) objects. However, this cost compounds when using rgbd with physics. 10 more complex objects (chefcan) results in greatly reduced performance, as expected.
• Realtime factor for this setup (with rgbd) is ~2.5x on 1 process and ~8x on 5 processes.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.